home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19970326-19970626
/
000020_news@columbia.edu _Sun Mar 30 13:17:52 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
4KB
Return-Path: <news@columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA07630
for <kermit.misc@watsun.cc.columbia.edu>; Sun, 30 Mar 1997 13:17:51 -0500 (EST)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA00693
for kermit.misc@watsun; Sun, 30 Mar 1997 13:17:50 -0500 (EST)
Path: news.columbia.edu!panix!news.eecs.umich.edu!news.radio.cz!newsbastard.radio.cz!news.radio.cz!CESspool!hammer.uoregon.edu!news.mathworks.com!howland.erols.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.os.ms-windows.nt.misc,comp.protocols.kermit.misc
Subject: Re: K95 Kermit flickers on Key Input in NT4.0
Message-ID: <1997Mar30.104144.96113@cc.usu.edu>
Date: 30 Mar 97 10:41:44 MDT
References: <5hbo8d$lbi$1@news.impulse.net> <5hh6tb$982$1@apakabar.cc.columbia.edu>
Organization: Utah State University
Lines: 51
Xref: news.columbia.edu comp.os.ms-windows.nt.misc:185311 comp.protocols.kermit.misc:6835
In article <5hh6tb$982$1@apakabar.cc.columbia.edu>, fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
> More on this...
>
> In article <5hh2ug$e5p$1@news.impulse.net>,
> Stephen Au <stephen@arktel.com> wrote:
> : >Frank da Cruz wrote:
> : >>In article <5hbo8d$lbi$1@news.impulse.net>,
> : >>Stephen Au <stephen@arktel.com> wrote:
> : >>:
> : >>: I have been using K95 under WIN95 for sometime and it works OK (slow)
> : >>:
> : >>Slow compared to what?
> :
> : Slow in couple respects, with serial connections @ 9600/19200 bps.
> :
> : #1. Compared to real-life WYSE-60 terminals at 9600/19200 bps.
> :
> Of course. A terminal is a special-purpose device that does nothing but
> "terminal emulation" -- routing incoming bytes directly to the screen
> (possibly after interpreting some escape sequences using some (usually) very
> tight machine code in its PROM), and routing keystrokes directly to the serial
> port -- often using two separate dedicated processors.
>
> : I grant that this "perception" of "slowness" is largely due to the pausing
> : between screen updates because I timed the output with a stop watch and the
> : result is similar. But on keyboard input, there is just this perceptible
> : delay between a key is depressed and a character appearing on the screen.
> : And it slows down productivity.
> :
> This does not happen to everybody. Most people see an instantaneous response.
> When there *is* a delay, it is caused by Windows' scheduling of Kermit 95's
> threads.
----------
Snipping out lots of neat technical discussion.
Just for perspective, MSK version 3.15 beta has a time of day clock
presentation on the terminal emulation status line. We found that simply
asking DOS for the current time of day, while waiting for bytes to arrive,
was enough to cause Win95 to shakily refresh the screen. Most annoying. I
had to add code to turn off the clock when MSK is run in Windows.
What this says is screen updating and sundry within Win95 is very
nervous. A screen refresh seems to be triggered by the slightest thing,
and that of course takes cpu time and tends to annoy users.
Now add back the many threads of Kermit95 with their systems calls,
and guess how Win95 can be frightened into updating the screen on every little
happenstance.
A lesson is comms programs should avoid the "o/s" as much as possible
and do all the work themselves, if allowed to come that close to the comms
machinery. MSK does this, being a DOS style program, but Windows programs
are not allowed to unless they are a VxD or similar.
Joe D.